<html>
	<head>
		<title>phpFaces</title>
<style type="text/css">

.article {
	margin: 1in;
}
	
.article h1 {
	size: .75em;	
}

.article p {
	line-height: 1.5em;
	text-indent: 5ex;
	margin: 0em 0em;
}

</style>
	</head>
	<body>
		<div class="article">

			<h1>Facelets: From JSF To PHP</h1>

<p>My goals are to provide an implementation of the Facelets 
	View Handler that is translated to Smarty, using its 
	native control structures when possible and custom 
	functions and blocks when necessary; a simple implementation 
	of FacesContext that provies Managed Beans and scoping for 
	use in the View Handler; and a simple Navigation Handler
	 that allows form actions and outcomes to be mapped to 
	destination views.</p>
			
			
<p>Smarty is a popular PHP template engine. Its popularity comes 
	from its simplicity and flexibility. While one can dive in with
	no knowledge of its advanced features, it leaves enough room for
	the most demanding of applications to customize it. Using Smarty 
	was an obvious choice for those reasons. By using custom block 
	handlers, functions, pre and post filters, and a resource stream,
	I was able to make Smarty parse Facelets files to native Smarty templates. 
	Because I fully utilized Smarty, the templates are still cachable and 
	compiled to pure PHP code upon their first use after a file modification,
	cutting out parsing all together for subsequent requests. The native PHP 
	compilation also lends itself to PHP accelerators such as Zend Optimizer,
	which brings further speed increases.</p>
			
<p>Facelets is a View Handler for JavaServer Faces(JSF) which replaces
	the default (and highly deplored) JSP View Handler. JSF was designed
	to be highly modular, therefor the spec defined a set of interfaces
	that allowed any different implementations of parts of the spec
	to be intermingled. The JSP View Handler suffers from many of the same
	problems that plague JSP itself, which is that it was designed for 
	a Model 2 web application. Facelets changes all that with an XML-based
	approach, making all JSF tags and display tags work in a harmony.</p>
			
<p>There are several advantages to implementing Facelets rather than sticking
	with a purely Smarty based view. Firstly, Facelets is much prettier to
	work with. While a template designer can, in theory, work with a Smarty template,
	the case is that the curly brackets often leave them scratching their head. 
	the ideal solution, in my experience, is to have the designer hand over a fully
	HTMLized version of their template, and have the programmer integrate it with 
	the application. The first step to making this work is creating a wireframe
	that both the designer and programmer will work off of, that way all the 
	components are known ahead of time and integration is less of a headache--there 
	are no surprises, therefore no compromises have to be made at this point! 
	Unfortunately this discussion is beyond the scope of this article, so let
	me carry on to my point: once a template is integrated with the application, 
	it is no longer maintainable by the designer because it is loaded with Smarty
	tags that they no longer have a clue about, and which their WYSIWYG editor 
	does no understand. Facelets, while also a non-HTML markup language has a trick
	up its sleeve, however. It is able to post as standard HTML (or anyML, for that mater) 
	tags by specifying the jsfc (JSF Compilation) attribute as the name of the tag<sup>2</sup>. With
	this ability, one can preview and make changes to the template without any knowledge
	of the facelets components existing. While it's true that an old WYSIWYG might destroy
	the tags in favor of its own (as they've been known to do, for me at least), they
	have been getting better about it over the years. Also, unlike Smarty, JSF is a "standard"
	technology, and has enormous vendor support (Oracle, IBM, Sun) behind it. While Facelets 
	is not a standard, (see: http://www.jsfcentral.com/articles/facelets_1.html)</p>
			
<p>The faces-config.xml file is used by JSF's default Navigation Handler. Like
	the View Handler, the Navigation Handler can also be decorated or downright 
	replaced; there is no widely used replacement Navigation Handler at this point,
	however. An example of one would be JBoss Seam, but it is not widely used. The 
	file defines several things, only a few of while phpFaces implements at this point. 
	Firstly, it defines Managed Beans. Managed Beans are classes that the
	framework manages. To you as a developer, this means that you don't have to 
	deal with instantiation or references, much less managing the state between requests.
	...more... As part of the lifetime cycle, JSF also takes care of mapping
	request values to managed bean properties<sup>move this</sup>. To specify a MB, you declare a name, a class name and a scope;
	the scope can be either request, session or application (the latter has been 
	omitted from phpFaces, however<sup>1</sup>). It also defines Navigation Rules. 
	Navigation Rules are the glue between 
	Managed Bean actions and their outcomes and the view. To define a
	rule, you specify: which view a user is coming from, what action 
	they executed from that view, the outcome of that action, and which
	view to take them to next. All of these components are optional, 
	depending on the combination of them, except the destination view. 
	One could make any out come of a given action always take the visitor to 
	a certain place, or a certain outcome of any action always take the
	visitor somewhere else, etc. This continues with the theme of
	simple yet flexible.</p>
	
<p>The VariableResolver class is another favorite... two way value binding and shit.</p>
					
		</div>
		
		
		<div class="article">

			<h1>Selenium: </h1>
			
<p>Selenium is an 'acceptance testing' framework which provides developers 
	with the ability to test not their code, but what actually happens when
	that code is executed. While JSF's approach to MVC makes it trivial to test
	backing beans and their actions, Selenium makes it easy to test what the user
	actually sees, and the process of interacting with the GUI as a human would.</p>
			
<p>Testing frameworks test constrains and ensure that software remains within them
	throughout the development process. Selenium integrates with 
	all popular web browsers to ensure that the GUI looks and, more importantly, behaves 
	as it should; normally they do it programatically through functions calls directly 
	to application code.</p>
		</div>
	</body>
</html>